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This is in response to the appeal brief filed 01/12/2009 appealing from the Office action 
mailed 06/16/2008 and Advisory Action mailed 10/07/2008. 

I. Real Party in Interest 

The real party in interest in this application and the appeal is contained in the 
brief. 

II. Related Appeals and Interferences 

Examiner is not aware of any related Appeals, Interferences or Judicial 
proceedings which will directly affect or be directly affected by or have a bearing 
on the Board's decision in this pending appeal. 

III. Status of Claims 

The statement of the status of Claims contained in the brief is correct. 

IV. Status of Amendments 

Appellant's statement of the status of amendments after final rejection contained 
in the brief is correct. 



V. 



Summary of the Claimed Subject Matter 

Summary of the Claimed subject matter contained in the brief is correct. 
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VI. Grounds of Rejections to be Reviewed on Appeal 

Appellant's statement of the grounds of rejection to be reviewed on Appeal is 
correct. 

VII. Claims Appendix 

Copy of the Appealed Claims contained in the Appendix to the brief is correct. 

VIII. Evidence Relied Upon 

Jouppi, Jarkkoetal. US 20030221016 A1 11/27/2003 

Krishnarajah; Ainkaran etal. US 7145919 B2 12/05/2006 

IX. Grounds of Rejection 

The following ground(s) of rejection are applicable to the Appealed Claims: 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 
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1. Claims 1, 7, 12-18, and 23-28 rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Patent Publication No. 20030221016 to Jouppi et al. (hereinafter 
"Jouppi"), as applied to claims above, and in view of US Patent No. 7145919 to 
Krishnarajah; Ainkaran et al., (hereinafter "Krishnarajah"). 

As to regards to Claim 1, Jouppi teaches method for performing Traffic Flow 
Template (TFT) filtering according to Internet Protocol (IP) versions in a mobile 
communication system, the method comprising the steps of (as stated in par. 0002, 
lines 1-6, The mobile station knows which application data flows are to be directed into 
which PDP context tunnel in the transmission of uplink data. In the direction of the 
downlink, the gateway GPRS support node GGSN must also know packet-specifically 
which PDP context is used for which data flow received from an external IP network. 
For this purpose, the destination IP address of the packet is used, and also TFT (Traffic 
Flow Template) templates are defined for the UMTS): 

extracting a first IP version address based information from a source second IP 
version address, wherein the second IP version address contains the first IP version 
address (as stated in par. 0002, lines 9-12, par. 0006, lines 19-22, mobile station 
transmits given values of TCP/UDP/IP address fields to the gateway GPRS support 
node GGSN for the identification of the flow. The TFT contains one or more so called 
packet filters. The filter functionality can be implemented by using not only an interface 
identifier but also other predetermined parameters and/or conditions with which the 
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packets or data flows can be identified in the IPv6 address structure. Examiner views 
Filtering understood as Extracting); 

and generating TFT information using the first IP version address, wherein the 
TFT information contains an indication that the second IP version address contains the 
first IP version address (as stated in par. 0039, lines 11-12, par. 0006, lines 19-22, The 
TFT can comprise at least the following filter parameters: source IP address, refers to 
the address of a peer device in an external network PDN, source gate, destination gate, 
DiffServ field (Differentiated Services), flow identifier (IPv6), protocol number (IPv4)/ the 
next address field (IPv6), etc.); 

and transmitting the TFT information to a Gateway GPRS (General Packet Radio 
Service) Support Node (GGSN) (as stated in par. 0039, line 2, lines 6-11, The mobile 
station MS transmits, TFT template, contents of the TFT template is transferred in a 
particular TFT information element, which can be used to create a new TFT, to remove 
an existing TFT and to add, remove or replace one or more filters of an existing TFT. 
The TFT is transmitted transparently through the SGSN). 

Krishnarajah in the same field of Networking Art also teaches, as stated in col. 
14, lines 38-57, In a UMTS architecture, UE which identifies a flow based on a set of 
parameters defined in a traffic flow template (TFT) which acts as a packet filter using 
filter parameters, like IP source/destination address, UDP source/destination address, 
etc., that are the same for an IP stream. The TFT is mapped to a specific GTP tunnel for 
which the PDF context was initiated. In the case where an IPv6 the flow label is used for 
flow identification, the UE initiates one TFT per flow and then maps it to the GTP tunnel. 
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In the RTP headier and destination option example implementations, only one TFT for 
the entire flow need be initiated since these example mechanisms do not modify any of 
the TFT parameters. Advantageously, introducing information in the IP flow label does 
not affect the TFT mechanism of directing each flow to the appropriate radio bearer. 
Although the flow label identify in the IPv6 header has been described here, similar 
identifiers in an IP packet, including in an IPv4 packet, may be used to indicate the 
subflows of a particular CODEC stream in order to perform different treatment on those 
subflows, e.g., a Type of service, TOS field in the IPv4 header could be redefined. 

Accordingly it would have been obvious to one of ordinary skill in the art at the 
time of the invention to incorporate teaching of TFT filtering of IPv6 packet as disclosed 
by Krishnarajah and to combine with that of Jouppi teaching and disclosure of TFT 
filtering, where TFT contains one or more so called packet filters based on IP version of 
the packet. The filter functionality can be implemented by using not only an interface 
identifier but also other predetermined parameters and/or conditions with which the 
packets or data flows can be identified in the IPv6/IPv4 address structures. 

The motivation would have been for filtering of flows based on IPv4 and or IPv6 
for reducing computation load, QoS, and defining class of flows of packet based on its 
IP version. 

Therefore, it would have been obvious to combine these two references of 
Jouppi's and Krishnarajah's disclosure to identify a flow/packet and transmit it on the 
radio bearer configured with the corresponding treatment/class of flow/packet filtering. 
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As regards to similar Claims 7 and 17, they are rejected on the same ground 
of reasoning as Claim 1, since TFT can comprise at least the following filter 
parameters: source IP address, refers to the address of a peer device in an external 
network PDN, source gate, destination gate, DiffServ field (Differentiated Services), flow 
identifier (IPv6), protocol number (IPv4)/the next address field (IPv6), etc. Based on the 
packet version, TFT can be created based on the IP packet version i.e. IPv6 and/or 
IPv4. TFT template is transferred in a particular TFT information element, parameter, 
which can be used to create a new TFT, to remove an existing TFT and to add, remove 
or replace one or more filters of an existing TFT. 

As regards to Claim 12, Jouppi teaches method as set forth in claim 1 further 
comprising: 

allowing User Equipment (UE) to perform the steps of extracting, generating TFT 
information and transmitting the generated TFT information to a Gateway GPRS 
(General Packet Radio Service) Support Node (GGSN) (as stated in par. 0035, lines 4- 
5, par. 0039, lines 6-11, par. 0025, lines, par. 0027, lines 1-5, The mobile station is 
responsible for adding and updating TFT templates. The mobile station MS transmits a 
TFT template, contents of the TFT template is transferred in a particular TFT 
information element, which can be used to create a new TFT, to remove an existing 
TFT and to add, remove or replace one or more filters of an existing TFT. The TFT is 
transmitted transparently through the SGSN, to the GGSN which receives the TFT 
template. Operation of the mobile station MS is divided into two devices, for example 
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into a computer (controller) operating as the terminal equipment TE and a UMTS 
communication device operating as mobile termination MT, the MT can observe the 
source IP addresses of applications of the TE and packets transmitted by the IP stack, 
particularly interface identifiers. Computer functions as TFT filter and stores TFT 
information in its memory); 

allowing the GGSN to store the TFT information received from the UE and to 
extract the first bits representing the first IP version address from the second IP 
version address when the second IP version address has the first IP version address 
inserted (as stated in par. 0037, lines 2-4, par. 0035, lines 16-26, Mobile station 
transmits TFT template, whereby the GGSN receives the TFT template in step 501 of 
FIG. 5, stores it in step 502 and uses it in step 504. On the basis of the requirements of 
the application, the MS determines for the PDP context request the quality of service 
QoS to be requested and for the TFT template the required filter information. On the 
basis of the request message, a new PDP context can be negotiated between the MS, 
SGSN and GGSN or an existing PDP context can be modified based on determined 
filter parameter of the PDP context TFT template (filter Fl) transmitted by the MS in 
question for the filter functionality FF of the gateway GPRS support node GGSN). 

and allowing the GGSN to perform the TFT packet filtering using the extracted 
first IP version address (as stated in par. 0031 , lines 9-1 1 , it is also easier and faster for 
the gateway GPRS support node GGSN to use the IPv4 and or IPv6 address as the 
filter parameter, for filter functionality FF of the gateway GPRS support node GGSN). 
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As regards to similar Claims 18 and 23-24, they are rejected on the same 
ground of reasoning as Claim 12. 

As regards to Claim 13, Jouppi teaches method as set forth in claims 1, 7, 12 or 
23, wherein the second IP version address into which the first IP version address is 
inserted is a first IP version-compatible second IP version address or a first IP version- 
mapped second IP version address (as stated in par. 0006, par. 0039-0040, in TFT 
filtering, part of the IP version address allocated by the terminal is used as a filter to 
guide mapping of data flows from a first subsystem to the terminal of a second 
subsystem. The interface identifier determined by the terminal refers to a bit sequence 
which reserves at least part of the bits determined for the interface identifier in the IPv6 
address structure. The packets fulfilling the conditions generally determined by the filter 
are transmitted by utilizing the associated data flow, in the UMTS (and GSM) system by 
utilizing the PDP context allocated to a wireless terminal. The filter functionality can be 
implemented by using not only an interface identifier but also other predetermined 
parameters and/or conditions with which the packets or data flows can be identified. 
FIG. 7 illustrates activation of a secondary PDP context in more detail. The mobile 
station MS transmits 701 an 'activate secondary PDP context' request to the SGSN, the 
request comprising a tunnel identifier of an activated PDP context, a new tunnel 
identifier, an NSAPI identifier, the requested QoS profile and a TFT template. The 
contents of the TFT template is transferred in a particular TFT information element, 
which can be used to create a new TFT, to remove an existing TFT and to add, remove 
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or replace one or more filters of an existing TFT. The TFT is transmitted transparently 
through the SGSN. The TFT can comprise at least the following filter parameters: 
source IP address (refers to the address of a peer device in an external network PDN), 
source gate, destination gate, DiffServ field (Differentiated Services), flow identifier 
(IPv6), protocol number (IPv4)/ the next address field (IPv6), security parameter index 
SPI in connection with the IPSec protocol, and according to the present preferred 
embodiment also an interface ID allocated by one or more mobile stations). 

As regards to similar Claim 25, is rejected on the same ground of reasoning as 
Claim 13. 

As regards to Claim 14, Jouppi teaches method as set forth in claims 13, and 
25, wherein the first IP version- compatible second IP version address is an address 
used between networks capable of supporting both a first IP of the first IP version and a 
second IP of the second IP version (as stated in par. 0004, lines 1-5, par. 0020, lines 1- 
17 and par. 0026, lines 1-17, the main parts of the mobile communication system are a 
core network CN and a terrestrial radio network UTRAN of the UMTS mobile 
communication system, which support both Ipv4 and Ipv6 to define the PDP address to 
be used for the mobile station). 

As regards to similar Claim 26, is rejected on the same ground of reasoning as 
Claim 14. 
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As regards to Claim 15, Jouppi teaches method as set forth in claims 13, and 
25, wherein the first IP version- mapped second IP version address is an address used 
between a network capable of supporting only a first IP of the first IP version and a 
network capable of supporting both the first IP of the first IP version and a second IP of 
the second IP version (as stated in par. 0004, lines 1-5 and par. 0026, lines 1-17, UMTS 
system support transmission of both Ipv4 and Ipv6 packets is applied to any packet- 
switched telecommunication system, wireless local area networks, Bluetooth systems, 
fourth-generation systems succeeding the UMTS system, or systems supporting 
packet-switched services of second-generation mobile communication systems, such as 
the GPRS system. The invention can also be applied to wired terminals and network 
elements supporting them). 

As regards to similar Claim 27, is rejected on the same ground of reasoning as 
Claim 15. 

As regards to Claim 16, Jouppi teaches method as set forth in claim 1, 7 or 12, 
wherein the first IP version is an IPv4 (IP version 4) and the second IP version is an IP 
version 6 (IPv6) (as stated in par. 0026, lines 1-17, for receiving and transmitting 
packet-switched data, the MS activates at least one PDP context which makes the MS 
known in the gateway GPRS support node GGSN and forms a logical data transmission 
context in the mobile station MS, in the serving GPRS support node SGSN and in the 
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gateway GPRS support node GGSN. In the establishment stage of the PDP context, a 
PDP address, which is an IPv4 or an IPv6 address (when the PDP type is IP), is 
determined for the MS). 

As regards to similar Claim 27, is rejected on the same ground of reasoning as 
Claim 28. 

X. Response to Arguments 

Examiner's understanding of the Claimed invention is that it is an apparatus and 
a method of Traffic Flow Template filtering of Internet Protocol packets in a 
mobile communication network, based on version of packet i.e. IPv6 and/or IPv4. 

The references and patent publications relied on by the examiner in the previous 
office actions demonstrate that not only were the components used in the 
apparatus available in the public domain at the time the invention was made, the 
integration of such components was also suggested by the references either 
explicitly or implicitly, making the claimed invention obvious for one of ordinary 
skill in the art to try with a reasonable expectation of success. 

A. Appellant argues (on page 6-9 of the Appeal Brief) that the references 
Jouppi and Krishnarajah, taken either singly or in combination, do not teach or 
suggest the subject matter recited in Claim 1 . 
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The Appellant cities the following statement regarding Jouppi reference: 
"Jouppi, which although is also related to IPv6 addresses as well as generating a 
TFT filter, is directed to a scheme aimed to solve a security problem, rather than 
a computation load problem. In particular, Jouppi is irrelevant to the claimed 
steps of extracting a first IP version address from a source second IP version 
address and generating TFT information using the first IP version address." 

In response: Examiner submits the following points. 
Jouppi as stated in par. 0006-0007, par. 0028-0029, discloses "interface identifier 
allocated by the terminal is used as a filter to guide mapping of data flows from a 
first subsystem to the terminal of a second subsystem. When the terminal 
allocates a new interface identifier, the network node attending to data 
transmission between the first subsystem and the second subsystem is first 
informed. 

Hereby, only transmission of packets comprising an interface identifier 
determined as a filter can be allowed, using a data flow to which the filter 
condition is associated. The interface identifier determined by the terminal refers 
to a bit sequence which reserves at least part of the bits determined for the 
interface identifier in the IPv6 address structure. 

The packets fulfilling the conditions generally determined by the filter are 
transmitted by utilizing the associated data flow, in the UMTS (and GSM) system 
by utilizing the PDP context allocated to a wireless terminal. The filter 
functionality can be implemented by using not only an interface identifier but also 
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other predetermined parameters and/or conditions with which the packets or data 
flows can be identified. 

In order to receive and transmit packet-switched data, the MS must 
activate at least one PDP context which makes the MS known in the gateway 
GPRS support node GGSN and forms a logical data transmission context in the 
mobile station MS, in the serving GPRS support node SGSN and in the gateway 
GPRS support node GGSN. 

In the establishment stage of the PDP context, a PDP address, which can 
be an IPv4 or an IPv6 address (when the PDP type is IP), is determined for the 
Mobile Station. The PDP address is determined in addition to other PDP context 
information, such as the negotiated QoS profile, for the context table maintained 
by the gateway GPRS support node GGSN. 

As illustrated in FIG. 4, the GGSN comprises a packet filter functionality 
FF, which attempts to identify a certain flow or a group of flows by including 
information on possible address fields in the form of packet filter components Fl. 

These packet filters Fl can comprise as at least one of their filter 
parameters an interface identifier that the MS has allocated to itself and indicated 
to the GGSN. The packet filters Fl are typically PDP-context-specific, whereby no 
other filter parameters are necessarily needed in addition to the interface 
identifier." 

Thus Appellant allegation regarding Jouppi's scheme is untrue as The 
interface identifier determined by the terminal refers to a bit sequence which 
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reserves at least part of the bits determined for the interface identifier (not all the 
64 bit as alleged) in the IPv6 address structure and the IPv6 addresses are 
formed of a prefix containing 64 bits and a suffix containing 64 bits, out of which 
32 bit suffix corresponds to IPv4 address. The interface identifier is a filter 
parameter of a TFT template used in the UMTS system. In such a case, the 
wireless terminal can activate the PDF context by using the interface identifier it 
has allocated. Since the wireless terminal in the GGSN network element 
operating as the edge node of the UMTS system is identified with the prefix of 
the IPv6 address when using IPv6 addresses, no prefix needs to be transferred 
in this case in messages relating to the activation of secondary PDP contexts, 
whereby the amount of information to be transmitted is smaller. The GGSN does 
not have to maintain prefixes for secondary PDP contexts either, nor does it have 
to check them, but the PDP contexts can be uniquely distinguished from each 
other on the basis of the interface identifier. 

B. Appellant argues (on page 9-11 of the Appeal Brief) that the Examiner's 
arguments are largely not directed to the subject matter recited in Claim 1 . 

The Appellant cities the following statement regarding Krishnarajah 
reference: 

"Turning to the cited secondary reference Krishnarajah, similar to Jouppi, 
the scheme disclosed in Krishnarajah is also irrelevant to the problem that the 
claimed combination advantageously resolves, that is, to reduce the bit- 
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computation load associated with performing TFT filtering operation. Specifically, 
Krishnarajah's scheme is designed to provide different priority treatments to 
different portions of a payload and therefore allow the scarce radio bandwidth to 
be used more efficiently by higher priority services." 

In response: Examiner submits the following points. 

Krishnarajah as stated in par. 0071 discloses, "In a UMTS architecture, 
the UE identifies a flow based on a set of parameters defined in a traffic flow 
template (TFT) which acts as a packet filter using filter parameters, like IP 
source/destination address, UDP source/destination address, etc., that are the 
same for an IP stream. The TFT is mapped to a specific GTP tunnel for which the 
PDP context was initiated. In the case where an IPv6 the flow label is used for 
flow identification, the UE initiates one TFT per flow and then maps it to the GTP 
tunnel. In the RTP header and destination option example implementations, only 
one TFT for the entire flow need be initiated since these example mechanisms 
do not modify any of the TFT parameters. Advantageously, introducing 
information in the IP flow label does not affect the TFT mechanism of directing 
each flow to the appropriate radio bearer. Although the flow label identify in the 
IPv6 header has been described here, similar identifiers in an IP packet, 
including in an IPv4 packet, may be used to indicate the subflows of a particular 
CODEC stream in order to perform different treatment on those subflows, e.g., a 
TOS field in the IPv4 header could be redefined." 
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Krishnarajah dose disclose identifying IPv6 packet and its corresponding 
flow label identity in an IP packet and states that similar identifiers including in an 
IPv4 packet may be used to indicate the subflows of a particular CODEC stream 
in order to perform different treatment on those subflows. Once the IP packet is 
identified as an IPv6 and/or IPv4 packet, in other words extracting the version of 
an IP packet, whether identified through an interface identifier and/or flow 
identifiers, traffic flow template filtering (TFT) can be applied to IP packets based 
on these parameters for extraction of IPv6 and IPv4 address. 

C. Appellant argues (on page 11-13 of the Appeal Brief) that 
In summary, Jouppi and Krishnarajah, taken singly or in combination, do not 
disclose, teach, or suggest extracting a first IP version address from a source 
second IP version address, wherein the second IP version address contains the 
first IP version address; and generating TFT information using the first IP version 
address, wherein the TFT information contains an indication that the second IP 
version address contains the first IP version address, as recited in claim 1. 
Accordingly, Jouppi and Krishnarajah, taken singly or in combination, do not 
disclose, teach, or suggest the subject matter recited in claim 1 . 

In response: Examiner submits the following points. 

Jouppi does disclose, that, "The contents of the TFT template is 
transferred in a particular TFT information element, which can be used to create 
a new TFT, to remove an existing TFT and to add, remove or replace one or 
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more filters of an existing TFT. The TFT is transmitted transparently through the 
SGSN. The TFT can comprise at least the following filter parameters: source IP 
address (refers to the address of a peer device in an external network PDN), 
source gate, destination gate, DiffServ field (Differentiated Services), flow 
identifier (IPv6), protocol number (IPv4)/ the next address field (IPv6), security 
parameter index SPI in connection with the IPSec protocol, and according to the 
present preferred embodiment also an interface ID allocated by one or more 
mobile stations." 

Thus Traffic Flow Template filtering parameters as described by Jouppi do 
perform extracting of the filtered parameters which can be based on the first IP 
version i.e. IPv4 version and also second IP version i.e. IPv6 version, in addition 
to that interface ID allocated by the mobile station. 

Similarly Krishnarajah also does disclose, "In a UMTS architecture, the UE 
identifies a flow based on a set of parameters defined in a traffic flow template 
(TFT) which acts as a packet filter using filter parameters, like IP 
source/destination address, UDP source/destination address, etc., that are the 
same for an IP stream. The TFT is mapped to a specific GTP tunnel for which the 
PDP context was initiated. In the case where an IPv6 the flow label is used for 
flow identification, the UE initiates one TFT per flow and then maps it to the GTP 
tunnel. In the RTP header and destination option example implementations, only 
one TFT for the entire flow need be initiated since these example mechanisms 
do not modify any of the TFT parameters. Advantageously, introducing 
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information in the IP flow label does not affect the TFT mechanism of directing 
each flow to the appropriate radio bearer. Although the flow label identify in the 
IPv6 header has been described here, similar identifiers in an IP packet, 
including in an IPv4 packet, may be used to indicate the subflows of a particular 
CODEC stream in order to perform different treatment on those subflows, e.g., a 
TOS field in the IPv4 header could be redefined." 

Krishnarajah dose disclose identifying IPv6 packet and its corresponding 
flow label identity in an IP packet and states that similar identifiers including in an 
IPv4 packet may be used to indicate the subflows of a particular CODEC stream 
in order to perform different treatment on those subflows. Once the IP packet is 
identified as an IPv6 and/or IPv4 packet, in other words extracting the version of 
an IP packet, whether identified through an interface identifier and/or flow 
identifiers, traffic flow template filtering (TFT) can be applied to IP packets based 
on these parameters for extraction of IPv6 and IPv4 address. 

The interface identifier determined by the terminal refers to a bit sequence 
which reserves at least part of the bits determined for the interface identifier in 
the IPv6 address structure. The filter functionality can be implemented by using 
not only an interface identifier but also other predetermined parameters and/or 
conditions with which the packets or data flows can be identified. 

The interface identifier is a filter parameter of a TFT template used in the 
UMTS system. In such a case, the wireless terminal can activate the PDF 
context by using the interface identifier it has allocated. Since the wireless 
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terminal in the GGSN network element operating as the edge node of the UMTS 
system is identified with the prefix of the IPv6 address when using IPv6 
addresses, no prefix needs to be transferred in this case in messages relating to 
the activation of secondary PDP contexts, whereby the amount of information to 
be transmitted is smaller. The GGSN does not have to maintain prefixes for 
secondary PDP contexts either, nor does it have to check them, but the PDP 
contexts can be uniquely distinguished from each other on the basis of the 
interface identifier. 

With regards to Jouppi disclosures bit computational associated with IPv6 
is reduced with the use of Interface identifiers. Similarly Krishnarajah Different 
types of headers may be used. For example, existing Internet protocol headers 
may be employed, and the mapping of a packet to a corresponding 
communications bearer may be determined using a standard IP header field. A 
specific, non-limiting, example embodiment is described below where the first 
and second IP packets are IP version 6 (IPv6) packets, and the mapping of each 
packet to a corresponding communications bearer is determined using the flow 
label of the IP header. In a UMTS architecture, the UE identifies a flow based on 
a set of parameters defined in a traffic flow template (TFT) which acts as a 
packet filter using filter parameters, like IP source/destination address, UDP 
source/destination address, etc., that are the same for an IP stream. The TFT is 
mapped to a specific GTP tunnel for which the PDP context was initiated. In the 
case where an IPv6 the flow label is used for flow identification, the UE initiates 
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one TFT per flow and then maps it to the GTP tunnel. Thus High priority, high 
quality of service, and/or important bits are identified and appropriately handled 
without having to treat all of the data in a payload using a higher treatment class 
which is expensive in terms of necessary resources. 

In conclusion Jouppi and Krishnarajah, taken singly or in combination, do 
disclose, teach, or suggest extracting through Traffic Flow Template filtering 
parameters which can be based on the first IP version i.e. IPv4 version and also 
second IP version i.e. IPv6 version. 

D. For the rest of the Claims under Appeal (i.e. Claims 7, 12-18 and 23-28), 
Appellant's arguments are all based on the disqualification of Jouppi and 
Krishnarajah as a prior art references for the reasons recited above, which has 
been responded to by the examiner accordingly. 

XI. Related Proceed inq(s) Appendix 

No decision rendered by a Court or the Board is identified by the examiner in the 
related Appeals and Interference section of this examiner's answer. 
For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 
/Muktesh G. Gupta/ 
Patent Examiner, Art Unit 2444 
/William C. Vaughn, Jr./ 
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